Blue Team Labs Online - MiddleMayhem

Incident Response

Tags: NextJS Splunk

Scenario The security team at MiddleMayhem Inc. has detected unusual network traffic to their admin portal, but no security breaches have been confirmed. Your SOC team has been provided with SIEM logs from the incident. Analyze the attack pattern to determine how attackers bypassed authentication, gained remote code execution, and moved laterally through the network.

Environment Awareness

Evidence & Tool Discovery

After deployed an investigation machine, we do not have much thing on our side beside the Splunk web interface and the website that was the target of this incident so we can interact with the website directly as well

We can now access Splunk web interface which after applied index=* and select time range to all time we will have 88,932 events combine from webapp and auth.log but we only have 50 events from auth.log, and it telling us that this event involves in SSH as well.

Beside this this investigation was released due to the popularity of Next.js middleware bypass vulnerability so we will need to understand this vulnerability first which I already prepared the blog post for you to read right here

Long Story short, Next.js use middleware to handle authorization such as admin to access authorized endpoint so this vulnerability present the oppotunity to bypass this middleware and jump straight to those endpoints by sending x-middleware-subrequest HTTP header with the right value (based on Next.js version)

Now lets start our investigation.

Investigation

Q1) Access the Website in the browser, present it in the bookmark, and identify the JavaScript framework and version used.

Since we can access to the website directly which after scrolling to the bottom, we have Next.js version right here and we can also see sitemap, robots and admin portal on this website, so all recipe for Next.js middleware bypass are here.

Next.js, 15.0.0

Q2) Using Splunk, Find the attacker’s IP address

Knowing which HTTP header will be used to bypass middleware, we can simply use the following query index=* source="webapp.csv" x-middleware-subrequest | sort by _time to filter all events which this header which we can see that not just an attempt to bypass to /admin endpoint which required authentication, the attacker also uploaded bash reverse shell (shell.sh) to /api/upload endpoint as well and both request came from the same IP address.

One more thing to notice is the value in the header which according to Project Discovery blog post, it matches the correct value to bypass Next.js version 13.2.0 or later.

218.92.0.204

Q3) Analyze the SIEM logs to determine how many unique URIs were accessed by the attacker.

We have 2 different query that could be use to find out about this, first is the stats count by http.request.uri and the second is dedup which both will get down to the same number which is 9930 different endpoints that where bruteforced by the attacker.

9930

Q4) Explore the site and identify two specific locations that could reveal internal structures or potential access points not meant for public eyes. Provide the two relative URLs.

The keyword here is "potential access points not meant for public eyes", and as we already found out the existence of robots.txt which is used to telling search engine's crawler to not index these endpoints which we get 2 endpoints from this file right here, both endpoint served as an initial access to upload reverse shell script as we discovered from Q2.

/admin, /admin/file-upload

Q5) Based on the Framework and Version, what recent CVE could be used to bypass authorization?

This Next.js middleware bypass vulnerability was assigned CVE number of CVE-2025-29927

CVE-2025-29927

Q6) Find the relevant HTTP header in the SIEM logs that indicates CVE exploitation. Provide the header name.

As we already talked and discovered what header being used to bypass middleware, its x-middleware-subrequest which was designed to use internally and the present of this header uses to "know if the middleware should be applied or not"

x-middleware-subrequest

Q7) What interesting URI did the attacker access after exploiting the CVE?

As we already discovered that /api/upload was used to upload shell.sh that will connect to 113.89.232.157 on port 31337 with netcat upon execution

/api/upload

Q8) The attacker tried uploading a reverse shell. Find out the IP and port to which the target would connect once the connection is established.

We know that after uploading reverse shell script, the attacker has to invoke this script in order to execute it and receive reverse shell so we could use index=* shell.sh which we can see that it will uploaded to /uploads/shell.sh

Then we could also use index=* 113.89.232.157 31337 query to filter for any event which this IP address and port which reveals incomplete 3-way handshake (SYN from server to C2 but RST, ACK from C2) and thats mean this connection was not established successfully due to C2 address sent RST packet back to victim.

113.89.232.157:31337

Q9) After compromising the WebApp server, the attacker attempted lateral movement. Identify the technique used, as recorded in the SIEM logs.

Somehow the attacker successfully compromised 172.217.164.174 despite what we discovered from previous question so now we have to look at the other source since we know that we have auth.log as other log source so it must be SSH

Which I used index=* source="/home/dbserv/auth.log" ssh | sort by _time to filter all events with "ssh" keyword and we will see that there is an brute force attack happened during the incident so the attacker attempted to gain access via SSH after compromised 172.217.164.174

SSH Brute Force

Q10) Identify the user account that achieved successful lateral movement to another server.

Then we can see that at the end, the attacker successfully connected to the target via SSH as dbserv user.

dbserv

https://blueteamlabs.online/achievement/share/52929/259